Draft Development

IHO Standard

S-122 Edition 1.2.1
Marine Protected Areas Product Specification
HSSC
IHO Standard

Draft Development

This document or partial material from this document may be translated, reproduced or distributed for general information, on no more than a cost recovery basis. Copies may not be sold or distributed for profit or gain without prior written agreement of the IHO and any other copyright holders.

In the event that this document or partial material from this document is reproduced, translated or distributed under the terms described above, the following statements are to be included:

“Material from IHO publication [reference to extract: Title, Edition] is reproduced with the permission of the International Hydrographic Organization (IHO) Secretariat (Permission No ……./…) acting for the International Hydrographic Organization (IHO), which does not accept responsibility for the correctness of the material as reproduced: in case of doubt, the IHO’s authentic text shall prevail. The incorporation of material sourced from IHO shall not be construed as constituting an endorsement by IHO of this product.”

“This [document/publication] is a translation of IHO [document/publication] [name]. The IHO has not checked this translation and therefore takes no responsibility for its accuracy. In case of doubt the source version of [name] in [language] should be consulted.”

The IHO Logo or other identifiers shall not be used in any derived product without prior written permission from the IHO.





Document History

Changes to this Specification are coordinated by IHO NIPWG. New editions will be made available via the IHO web site. Maintenance of the Specification shall conform to IHO Resolution 2/2007 (as amended).

Table — Document History

Version NumberDateApproved ByPurpose

1.0.0

April 2012

TSMAD

Approved edition of S-102

2.0.0

March 2017

S-102PT

Updated clause 4.0 and 12.0.
Populated clause 9.0 and Annex B.

#include::sections/01-overview.adoc[]

#include::sections/02-spec_scope.adoc[]

#include::sections/03-data_product_id.adoc[]

#include::sections/04-data_content_struct.adoc[]

1  Coordinate Reference Systems (CRS)

1.1  Introduction

The Coordinate Reference System information contained in Table 1-1 is defined in the manner specified in part=6. The vertical datum is specified separately using other root group attributes.

1.2  Horizontal Coordinate Reference System

Table 1-1 — S-102 Coordinate Reference Systems (EPSG Codes)

EPSG CodeCoordinate Reference System
4326WGS84
32601 — 32660WGS 84 / UTM Zone 1N to Zone 60N
32701 — 32760WGS 84 / UTM Zone 1S to Zone 60S
5041WGS 84 / UPS North (E,N)
5042WGS 84 / UPS South (E,N)
The full reference to EPSG can be found at https://epsg.org.
Horizontal Coordinate Reference System

EPSG (see Table 1-1)

Projection

NONE/UTM/UPS

Temporal reference system

Gregorian Calendar

Coordinate Reference System registry

EPSG Geodetic Parameter Dataset

Date type (according to [iso-19115-1])

002 — publication

Responsible party

International Association of Oil & Gas Producers (IOGP)

URL

https://www.iogp.org/

1.3  Vertical Coordinate Reference System

Although in this product there are no direct vertical coordinates the values of the depth attributes are indirectly such coordinates. Therefore, it is important to specify the vertical CRS to which these values conform. The vertical CRS is an earth gravity-based, one-axis coordinate system. The Orientation of the axis is defined by the vertical coordinate system attribute (verticalCS) in the root group (see Table 6-2).

The vertical datum must be taken from the code-list specified by the IHO Geospatial Information (GI) Registry for the attribute named Vertical Datum. It will be defined in the root group as an HDF5 attribute (see Table 6-2).

1.4  Temporal reference system

The temporal reference system is the Gregorian calendar for date and UTC for time. Time is measured by reference to Calendar dates and Clock time in accordance with clause=5.4.4. A date-time variable will have the following 16-character format: yyyymmddThhmmssZ.

2  Data Quality

Data quality allows users and user systems to assess fitness for use of the provided data. Data quality measures and the associated evaluation are reported as metadata of a data product. This metadata improves interoperability with other data products and provides usage by user groups that the data product was not originally intended for. The secondary users can make assessments of the data product usefulness in their application based on the reported data quality measures.

2.1  Completeness

2.1.1  Commission

Commission is applicable for S-102. Data Producers must verify that no excess items have been included in the dataset. Such excess items include duplicate items, which must be removed.

If no excess items are present, the dataset PASSES this test.

2.1.2  Omission

Omission is applicable for S-102. Data Producers must verify that no items that should have been included in the dataset have been omitted.

If no necessary items have been omitted, the dataset PASSES this test.

2.2  Logical consistency

2.2.1  Conceptual consistency

Conceptual Consistency is applicable for S-102 and follows the guidelines from part=1.

Data Producers must verify that the dataset conforms to the S-100 General Feature Model.

If the dataset conforms to the S-100 General Feature Model, the dataset PASSES this test.

2.2.2  Domain consistency

Domain consistency is applicable for S-102 and follows the guidelines from part=5.

Data Producers must verify that the dataset conforms to the S-102 Feature Catalogue and to Annex A.

If the dataset conforms to the S-102 Feature Catalogue and to Annex A, the dataset PASSES this test.

2.2.3  Format consistency

Format Consistency is applicable for S-102 and follows the guidelines from part=10c.

Data Producers must verify that the dataset conforms to Section 6 of this Product Specification.

If the dataset conforms to Section 6, the dataset PASSES this test.

2.3  Positional accuracy

2.3.1  Gridded data positional accuracy

Gridded positional accuracy is defined by the precision of the positional reference used to specify its location within its spatial projection. These positional references are contained within the spatial metadata of the S-102 grid. It is assumed that any horizontal errors are assimilated into the vertical uncertainty. The vertical values are calculated for each grid point using the processes and procedures used by each hydrographic office during the creation of the S-102 grid. Appropriate selection of both the origin reference point and spatial resolution are important and are another factor in gridded positional accuracy.

2.3.2  Relative internal positional accuracy

The internal positional accuracy is defined as the precision of the location of each grid point within the S-102 grid. The position of each grid point within the grid is referenced by a row and column combination. The metadata for S-102 defines a gridded resolution along both the X and Y axis of the grid. This absolute position of a grid point within the spatial projection of the grid is calculated using the row/column and the X/Y resolution. In this case, the accuracy is controlled by the precision used in defining these resolutions.

2.4  Temporal accuracy

Temporal accuracy, consistency, and validity of bathymetric grids are confined to elements of the vertical control processes. These aspects are addressed during the formulation and application of vertical control processes applied by the various hydrographic offices. Details of these processes will be included in the Lineage portion of the metadata defined in Section 8 of this Product Specification.

2.5  Thematic accuracy

2.5.1  Thematic classification correctness

For S-102 bathymetric grids there are two classifications of data values, which are land and water. There are two considerations for assessing classification correctness when using the grid. The first is that values given in the depth layer of the S-102 grid are based on the associated hydrographic office’s chosen vertical datum. Should another value in relation to a different vertical datum be required, a series of correctors would need to be applied. Secondly, when considering the data values, the value stored in the uncertainty for a given grid point must be considered. This uncertainty value represents the magnitude of possible deviation in either direction from the data value and must be applied when assessing the classification correctness. The new value generated when applied may cause a change in the classification.

2.5.2  Non-quantitative attribute accuracy

Thematic accuracy of S-102 bathymetric data is wholly quantitative.

2.5.3  Quantitative attribute accuracy

As defined in part=4c the data quality for the depth coverage is also defined as a co-located optional coverage, which is the uncertainty. This value particularly refers to the vertical uncertainty at each grid point. The uncertainty coverage supports multiple definitions of vertical uncertainty.

See Table 6-9.

3  Data Capture and Classification

The DCEG describes how data describing the real world should be captured using the types defined in the S-102 Feature Catalogue. The DCEG is located at Annex A.

A number of sounding techniques are used to capture bathymetric data. It is permitted, but not required, to include data acquisition information in the metadata of an S-102 Bathymetric Surface product. The metadata class S102_AcquisitionMetadata has been defined, but the information elements to populate this metadata class should be identified in a national profile of S-102.

3.1  Quality and source metadata

Quality and source metadata in S-102 are intended to enable and support future navigation software to appropriately auto-generate and attribute cartographic features such as custom depth contours and soundings from S-102 products, all while minimally impacting the overall file size of the product.

Quality and source metadata are encoded in a feature attribute table compliant with both HDF5 and S-100. This feature attribute table will provide valuable information about the bathymetry on a grid cellwise basis compared to traditional vector-based metadata files, simplifying the interpretation and implementation by navigation software systems.

The fields of the feature attribute table are defined elsewhere in this Product Specification (Table 6-7).

Quality and source metadata in S-102 are based on S-101 quality attributes, with significant augmentations and omissions described below. The quality and source metadata support a threefold purpose:

  1. Support S-101-defined attribution of auto-generated vector depth areas, depth contours, and soundings created directly from the S-102 dataset.

    1. The attribute featureSizeVar is meant to augment featureSize which corresponds to S-101 size of features detected. As noted in S-101, size of features detected is intended to be described as the smallest size in cubic metres the survey was capable of detecting. Depending on various survey parameters, this definition might require different depth ranges to have different values. For example, a survey vessel working at a fixed height off the seafloor (such as an autonomous underwater survey vessel) could maintain a fixed feature detection size capability over a wide range of depths. Conversely, a surface vessel working over that same range of depths may have a feature detection capability that varies with depth. The latter situation could foreseeably cause the detection capability to be ambiguous and potentially misrepresented. For this reason, featureSizeVar is defined as the ratio (expressed as a percentage) of minimum detectable feature size to water depth. When both featureSize and featureSizeVar are present, the whichever value implies a larger feature size should be considered valid. The expectation is that featureSizeVar will be set to zero if the feature size does not scale with depth. As with featureSize, featureSizeVar should be ignored if significantFeatures is False.

    2. Note that depth range maximum and minimum in S-101 are omitted. The assumption is that if this information is required, then the corresponding grid cells in the elevation layer can be queried for a minimum and maximum depth for each table row.

  2. Provide necessary uncertainty information as an input into critical underkeel clearance precision navigation systems.

  3. Prevent the automated selection of soundings from interpolated grid cells, while still providing the continuous data required for depth contour creation. This purpose is accomplished by the bathyCoverage Boolean attribute field. This field enables the flagging of grid cells populated by interpolation (when that interpolation occurs across gaps in bathymetric observations greater than the S-102 grid spatial resolution). This functionality is especially useful in side-scan surveys which are characterized by gaps in bathymetric observations with full coverage side-scan imagery. In this case, interpolated gaps between bathymetry coverage would show fullSeafloorCoverageAchieved = True and bathyCoverage = False. However, if fullSeafloorCoverageAchieved = False, bathyCoverage must also equal False (e.g., gaps between single beam echosounder data without correlating side scan sonar coverage). Thus, this facility will provide navigation software systems with the required information necessary to preferably select soundings from direct bathymetric observations.

Quality and source metadata are encoded as records within a featureAttributeTable dataset, which is itself within the QualityOfBathymetryCoverage container group (Table 6-7).

4  Data Maintenance

4.1  Maintenance and update frequency

Datasets are maintained by replacement on a dataset basis. That is, the entire data product and the associated metadata are replaced as a unit. This is unlike vector data that may be updated incrementally. Also, each replacement data set must have its own digital signature.

4.2  Data source

Data producers must use applicable sources to maintain and update data and provide a brief description of the sources that were used to produce the dataset.

4.3  Production process

Data Producers should follow their established production processes for maintaining and updating datasets.

5  Portrayal

5.1  Introduction

S-102 portrayal is intended to contribute to the safe operation of an S-100 based marine navigation system by:

  • Ensuring display of bathymetric surfaces, standards of colours, and their assignment to depths;

  • Ensuring the display is clear and unambiguous;

  • Establishing an accepted pattern for presentation that becomes familiar to mariners and so can be recognized instantly without confusion; and

  • Utilizing the S-100 portrayal model to ensure interoperability.

To ensure that presentation remains intuitive, the following principles must be followed when changes are made to the S-102 Portrayal Catalogue:

  • S-102 must maintain equivalence in terms of alerts and indications functionality in ECDIS;

  • The S-102 Portrayal Catalogue should be modified by extension. Portrayal rules should be retained for items that have been superseded in the current version of S-102. This retention ensures that S-102 data produced to previous versions can be displayed using the latest Portrayal Catalogue.

S-102 portrayal is covered by the portrayal model as defined in S-100. This model reflects how the Portrayal Catalogue is defined for use in marine navigation systems.

S-102 uses the portrayal processes defined in part=9 and part=9a. Items included in the S-102 Portrayal Catalogue must be registered in the IHO Geospatial Information (GI) Registry.

5.2  Portrayal Catalogue

Citation information for the S-102 Portrayal Catalogue is provided in Table 5-1 below.

Table 5-1 — S-102 Portrayal Catalogue Citation Information

No.ISO class or attributeTypeValue

CI_Citation

Class

1

title

Character String

S-102 Portrayal Catalogue

2

date

CI_Date
(class)

2.1

date

DateTime

2024-06-11T00:00:00

2.2

dateType

CI_DateTypeCode
(ISO codelist)

publication

3

edition

CharacterString

3.0.0

4

editionDate

DateTime

2024-06-11T00:00:00

5

citedResponsibleParty

CI_responsibility
(class)

5.1

role

CI_RoleCode
(ISO codelist)

publisher

5.2

party

CI_Organisation
(class)

5.2.1

name

CharacterString

International Hydrographic Organization

6

otherCitationDetails

CharacterString

Found under:
GI Registers
Product Specifications
Bathymetric Surface

7

onlineResource

CI_OnlineResource
(class)

7.1

linkage

CharacterString
(URL)

https://registry.iho.int/

7.2

name

CharacterString

S-102 Portrayal Catalogue

7.3

description

CharacterString

XML Portrayal Catalogue accompanied by related files for colour profiles, rules, etc.

The S-102 Portrayal Catalogue contains the mechanisms for the system to portray information found in S-102 bathymetric surfaces. The S-102 Portrayal Catalogue contains the following types of mechanisms and structures:

  • Set of portrayal rules;

  • Set of colour profiles.

The Portrayal Catalogue model is defined in part=9,clause=9-13. The S-102 Portrayal Catalogue is available in an XML document, which conforms to the S-100 XML Portrayal Catalogue Schema. The structure for the Portrayal Catalogue is described in part=9,clause=9-13.2.

Figure 5-1 is included to illustrate informative depth zone colouring as adapted from S-52. More comprehensive portrayal details can be found in the S-102 Portrayal Catalogue, which is available in the IHO GI Registry (as detailed in Table 5-1).

Depiction of a seafloor area coloured according to S-52 Ed. 6.1.1 for Day

Figure 5-1 — S-52, Edition 6.1(.1) Depth Zone Colouring for Day

5.2.1  Use of sun-illumination

S-102 data can be visualized as a sun-illuminated or static (flat) dataset. The depiction of sun-illumination requires the entry of a sun azimuth and corresponding elevation. Figure 5-2 shows the difference between a sun-illuminated and static (flat) surface.

NOTE  Although sun-illumination provides marked benefit to the user, it is not currently supported by S-100. As such, it is advisable for ECDIS manufacturers to implement the facility of sun-illumination in order to make such a benefit available.

Informative values for sun azimuth angle and elevation have been provided in Table 5-2 below.

Table 5-2 — Sun Azimuth and Elevation Values

AttributeValue in Degrees
Sun-IlluminatedFlat Surface
Sun Azimuth Angle135 Degrees0.0 Degrees
Sun Elevation45 Degrees0.0 Degrees
Side-by-side depiction of a seafloor area with and without sun-illumination. Both views show varying gray shades as depth varies by a large amount. The left view is labeled _Sun-Illuminated_ and also shows hillshade effects according to all depth variation. The right view is labeled _Flat_ and shows no hillshading.

Figure 5-2 — Sun-illuminated and Static (Flat) Shading

6  Data Product Format (Encoding)

6.1  Introduction

The S-102 data set must be encoded using the Hierarchical Data Format standard, Version 5 (HDF5).

Format Name

HDF5

Version

1.8.8

Character Set

UTF-8

Specification

https://www.hdfgroup.org/

The key idea behind the S-102 product structure is that each coverage is a feature. Each of these features is co-located with the others. Therefore, they share the same spatial metadata, and each is required to correctly interpret the others.

For the use of HDF5, the following key concepts (part=10c,clause=5.1) are important:

File

a contiguous string of bytes in a computer store (memory, disk, etc.), and the bytes represent zero or more objects of the model;

Group

a collection of objects (including groups);

Dataset

a multidimensional array of data elements with attributes and other metadata;

Dataspace

a description of the dimensions of a multidimensional array;

Datatype

a description of a specific class of data element including its storage layout as a pattern of bits; (Enumerations are encoded with unsigned 8-bit or unsigned 16-bit indices, depending on the number of transported values.)

Attribute

a named data value associated with a group, dataset, or named datatype and stored as a scalar;

Property List

a collection of parameters (some permanent and some transient) controlling options in the library.

In addition, datasets may be a compound (a single record consisting of an array of simple value types) and have multiple dimensions.

6.2  Product structure

The structure of the data product follows the form given in part=10c — HDF5 Data Model and File Format. The general structure, which was designed for several S-100 products is given in Figure 6-1.

UML diagram depicting the generic data file structure as described between this figure and the table Overview of S-102 Data Product

Figure 6-1 — Outline of the generic data file structure

Figure 6-1 shows the four levels defined within the HDF encoding as defined in part=10c. Below is a further definition of these levels.

Level 1

At the top level lies the Root Group, and it contains the Root Metadata and two subsidiary groups. The Root Metadata applies to all S-100 type products.

Level 2

The next Level contains the Feature Information Group and the Feature Container Group. The Feature Information Group contains the feature BathymetryCoverage, the feature attribute codes and the optional feature QualityOfBathymetryCoverage. The Feature Container Group contains the Feature Metadata and one or more Feature Instance Groups.

Level 3

This level contains one or more Feature Instance groups. A BathymetryCoverage feature instance is a bathymetric gridded data set for a single region and at a single vertical datum. A QualityOfBathymetryCoverage feature instance is a corresponding dataset for the same single region and for all applicable vertical datums.

Level 4

This level contains the actual data for each feature. In S-102 BathymetryCoverage and QualityOfBathymetryCoverage each use the ValuesGroup to define the content. The other groups at this level are not used.

In Table 6-1 below, levels refer to HDF5 structuring (see Figure 6-1). Naming in each box below the header line is as follows: Generic name; S-100 or S-102 name, or nothing if none; and (HDF5 type) group, attribute or attribute list, or dataset. Figure 6-2 depicts the same structure using a graphical representation.

Table 6-1 — Overview of S-102 Data Product

LEVEL 1 CONTENTLEVEL 2 CONTENTLEVEL 3 CONTENTLEVEL 4 CONTENT

General Metadata
(metadata)
(h5_attribute)

Feature Codes
Group_F
(h5_group)

Feature Name
BathymetryCoverage
(h5_dataset)

QualityOfBathymetryCoverage
(h5_dataset)

Feature Codes
featureCode
(h5_dataset)

Feature Type
BathymetryCoverage
(h5_group)

Type Metadata
(metadata)
(h5_attribute)

Feature Instance
BathymetryCoverage.01
…​
BathymetryCoverage.nn
(h5_group)

Instance Metadata
(metadata)
(h5_attribute)

First data group
Group_001
(h5_group)

Group Metadata
(metadata)
(h5_attribute)

X and Y Axis Names
axisNames
(h5_dataset)

Bathymetric Data Array values
(h5_dataset)

Feature Type
QualityOfBathymetryCoverage
(h5_group)

Metadata
(h5_attribute)
(same as BathymetryCoverage)

QualityOfBathymetryCoverage.01
(h5_group)

Group_001
(h5_group)

Group Metadata
(metadata)
(h5_attribute)

X and Y Axis Names
axisNames
(h5_dataset)

Quality of Bathymetry Data Array
values
(h5_dataset)

Feature Attribute Table
(h5_dataset)

Diagram depicting hierarchical structure of S-102 Data Product. Let the following block names be represented by letters. A=Group_F ; B=BathymetryCoverage ; C=QualityOfBathymetryCoverage ; D=BathymetryCoverage ; E=QualityOfBathymetryCoverage ; F=featureCode ; G=BathymetryCoverage.01 ; H=…​ ; I=BathymetryCoverage.nn; J=axisNames ; K=QualityOfBathymetryCoverage.01 ; L=featureAttributeTable ; M=axisNames; N=Group_001 ; O=Group_001 ; P=Group_001; Q=Group_001; R=values ; S=values; T=values; U=values. A, B, and C reside in Level 1. A connects to D, E, and F in Level 2. B connects to G, H, I, and J in Level 2. C connects to K, L, and M in Level 2. G connects to N in Level 3. H connects to O in Level 3. I connects to P in Level 3. K connects to Q in Level 3. N connects to R in Level 4. O connects to S in Level 4. P connects to T in Level 4. Q connects to U in Level 4.

Figure 6-2 — Hierarchy of S-102 Data Product

The following sections explain entries in Table 6-1 in greater detail.

6.2.1  Root Group

The root group is required by HDF5. The S-100 HDF5 format (part=10c) attaches metadata attributes applicable to the whole dataset to this group. S-102 uses all the S-100 attributes except geographicIdentifier and metaFeatures. The attributes used in S-102 are listed in Table 6-2, with specific requirements, if any, added in the Remarks column.

Table 6-2 — Root group attributes

NoNameCamel CaseMultData TypeRemarks

1

Product specification number and version

productSpecification

1

String

part=10c,table=6
Example: INT.IHO.S-102.3.0.0

2

Time of data product issue

issueTime

0..1

String (Time format)

part=1,table=2
part=10c,table=1

3

Issue date

issueDate

1

String (Date format)

part=1,table=2
part=10c,table=1

4

Horizontal CRS

horizontalCRS

1

Integer
32-bit

The identifier (EPSG code) of the horizontal CRS as defined in Clause 1.2 (see Clause 6.2.1, Note 2).

5

Epoch of realization

epoch

0..1

String

6a

Bounding box

westBoundLongitude

1

Float
32-bit

The values are in decimal degrees.
If a projected CRS is used for the dataset, these values refer to those of the baseCRS underlying the projected CRS (see Clause 6.2.1, Note 3).

The root bounding box needs to encompass all data, including fill values. The outermost cell boundaries of the grid cells and the bounding box / domain extent polygon of each feature instance group form the basis for the root bounding box.

6b

eastBoundLongitude

1

Float
32-bit

6c

southBoundLatitude

1

Float
32-bit

6d

northBoundLatitude

1

Float
32-bit

7

Metadata

metadata

0..1

String

Name of metadata file
MD_<HDF5/>file base name>.XML (or .xml) ISO metadata
(per part=10c,clause=12 & part=8).

8

Vertical coordinate system

verticalCS

1

Integer
32-bit

Mandatory in S-102.
EPSG code;

The only allowed value is:
*6498 (Depth—​metres—​orientation down)

9

Vertical coordinate base

verticalCoordinateBase

1

Enumeration

Mandatory in S-102.
The only allowed value is 2: verticalDatum
(see part=10c,table=22).

10

Vertical datum reference

verticalDatumReference

1

Enumeration

Mandatory in S-102.
The only allowed value is 1: s100VerticalDatum
(see part=10c,table=23).

11

Vertical datum

verticalDatum

1

Integer
unsigned
16-bit

Numeric code from IHO GI Registry
Vertical Datum attribute
1 30 & 44

see Clause 6.2.1, Note 4

NOTE 1  The productIdentifier (“S-102”) and version fields (X.X.X) of S100_ProductSpecification must be used.

NOTE 2  The value horizontalCRS specifies the horizontal Coordinate Reference System. At the time of writing, S-100 does not yet provide a mechanism for this value’s definition within HDF5 encoding (such as an enumeration of horizontal CRSs). Consequently, this configuration causes a deviation from S-100. The horizontal datum is implicitly defined by this CRS because each horizontal CRS consists of a coordinate system and a datum. S-102 does not use “user defined” CRS as mentioned in part=10c,table=6.

NOTE 3  The baseCRS is the geodetic CRS on which the projected CRS is based. In particular, the datum of the base CRS is also used for the derived CRS (see part=6,table=6).

NOTE 4  This is the default vertical datum. If and only if a BathymetryCoverage feature instance group does not specify a vertical datum, this (Root Group) vertical datum shall apply.

6.2.2  Feature Codes (Group_F)

No attributes.

This group specifies the S-100 features to which the data applies, and consists of three components:

featureCode — a 1-dimensional dataset with the featureCode(s) of the S-100 feature(s) contained in the data product. For S-102, the dataset has only two elements — the string “BathymetryCoverage” and “QualityOfBathymetryCoverage” (without quotes). The entries in this dataset give the names of the other two components of Group_F.

BathymetryCoverage — A 1-dimensional dataset that contains the standard definition of the bathymetry coverage feature class in terms of its attributes and their types, units of measure, etc. The datatype of its elements is the compound type described in part=10c,table=8.

QualityOfBathymetryCoverage — A 1-dimensional dataset of the same datatype as the BathymetryCoverage dataset described above. This QualityOfBathymetryCoverage dataset contains the definition of the reference to metadata records. The reference is a single integer which identifies a metadata record in featureAttributeTable (described in part=10c,clause=9.6.2 and Clause 6.2.8.

6.2.3  BathymetryCoverage and QualityOfBathymetryCoverage Tables (in Group_F)

BathymetryCoverage and QualityOfBathymetryCoverage are arrays of compound type elements, whose components are the 8 components specified in Table 6-3.

Table 6-3 — Sample contents of the BathymetryCoverage and QualityOfBathymetryCoverage arrays

NameExplanationBathymetryCoverageQualityOfBathymetryCoverage

S-100 Attribute 1

S-100 Attribute 2

S-100 Attribute 1

code

Camel Case code of attribute as in Feature Catalogue

depth

uncertainty

iD

name

Long name as in Feature Catalogue

depth

uncertainty

ID

uom.name

Units (uom.name from S-100 Feature Catalogue)

metres

metres

(empty)

fillValue

Fill value (integer or float, string representation, for missing values)

1000000

1000000

0

datatype

HDF5 datatype, as returned by H5Tget_class() function

H5T_FLOAT

H5T_FLOAT

H5T_INTEGER

lower

Lower bound on value of attribute

-14

0

1

upper

Upper bound on value of attribute

11050

(empty)

(empty)

closure

Open or Closed data interval. See S100_IntervalType in part=1.

closedInterval

geSemiInterval

geSemiInterval

NOTE  The uncertainty attribute of BathymetryCoverage may be omitted under certain conditions. See Clause 6.2.7.

According to part=10c,clause=9.5, “All the numeric values in the feature description dataset are string representations of numeric values; for example, “-9999.0” not the float value -9999.0.”

While the sample contents are shown in the two attributes columns, these are actually rows in the BathymetryCoverage table. They are also each a single HDF5 compound type and represent a single HDF5 element in the table.

All cells shall be HDF5 variable length strings. The minimum and maximum values are stored in lower and upper columns. Variable length strings allow future proofing the format in the event editing is allowed or correcting these values is required.

6.2.4  Root BathymetryCoverage

Table 6-4 — Attributes of BathymetryCoverage feature container group

NoNameCamel CaseMultData TypeRemarks
1Data organization indexdataCodingFormat1EnumerationValue: 2
2Dimensiondimension1Integer
unsigned
8-bit
Value: 2
3Common point rulecommonPointRule1EnumerationValue: 2 (low)
see part=8,table=11.
4Horizontal position uncertaintyhorizontalPositionUncertainty1Float
32-bit
Value: -1.0 (if unknown or not available)
5Vertical position uncertaintyverticalUncertainty1Float
32-bit
Value: -1.0 (if unknown or not available)
6Number of feature instancesnumInstances1Integer
unsigned
8-bit
This is the total number of Feature Instance Groups within the Feature Container Group.
The minimum is 1.
see Clause 6.2.4, Note
7aSequencing rulesequencingRule.type1EnumerationValue: 1 (linear)
see part=8,table=12.
7bsequencingRule.scanDirection1StringValue: <axisNames entry> (comma-separated).
For example, “latitude,longitude”. Reverse scan direction along an axis is indicated by prefixing a ‘-’ sign to the axis name. See [scanDirection]
8Interpolation typeinterpolationType1EnumerationValue: 1 (nearestneighbor). See part=8,table=13
9Offset of data point in celldataOffsetCode1EnumerationValue: 5 barycenter (centroid) of cell. See part=10c,table=10

NOTE  The number depends on the number of different vertical datums in the Feature Container Group.

6.2.5  Feature Instance group — BathymetryCoverage.nn

The BathymetryCoverage Feature Container Group can contain one or more Feature Instance Groups. The naming of the Feature Instance Groups follows the notation specified by the S-100. For generalization, the numbering is indicated with “.nn”.

Each feature instance group implements a unique vertical datum. All feature instance groups must share the same spatial location and extent. For each feature instance group, only the grid cells falling within the area of validity for that feature instance group’s vertical datum should be populated with (real) data. Within that feature instance group, all other grid cells should be populated with the fill value. Therefore, it is expected that:

  • The only grid cells that should be populated in more than one feature instance group are those that fall along a vertical datum boundary.

  • Where multiple population occurs, the ECDIS should choose the set of values resulting in the most conservative description to the mariner. (I.e., it should choose the shoalest adjusted depth.)

As derived from part=10c,clause=9.7 and part=10c,table=12, Table 6-5 and Table 6-6 describe the structure and attributes, respectively, of the BathymetryCoverage feature instance group.

Table 6-5 — Structure of BathymetryCoverage feature instance group

GroupHDF5
Category
NameMultData TypeRemarks / Data Space
/BathymetryCoverage/
BathymetryCoverage.01
attributes(see Remarks)1(see Remarks)Single-valued attributes as descripted in Table 6-6
DatasetdomainExtent.polygon0..1Compound
(Float, Float)
Spatial extent of the domain of the coverage
Array (1-d): i=0, P
Components: <longitude/>, latitude> or <X/>, Y> (coordinates of bounding polygon vertices as a closed ring; that is, the first and last elements will contain the same values)
Either this or the bounding box attribute must be populated.
/BathymetryCoverage/
BathymetryCoverage.nn
attributes(see Remarks)1(see Remarks)Single-valued attributes as descripted in Table 6-6
DatasetdomainExtent.polygon0..1Compound
(Float, Float)
Spatial extent of the domain of the coverage
Array (1-d): i=0, P
Components: <longitude/>, latitude> or <X/>, Y> (coordinates of bounding polygon vertices as a closed ring; that is, the first and last elements will contain the same values)
Either this or the bounding box attribute must be populated.

Table 6-6 — Attributes of BathymetryCoverage feature instance group

NoNameCamel CaseMultData TypeRemarks
1aBounding boxwestBoundLongitude0..1Float
32-bit
Coordinates should refer to the previously defined Coordinate Reference System.
Either this or the domainExtent.polygon dataset must be populated
1beastBoundLongitude0..1Float
32-bit
1csouthBoundLatitude0..1Float
32-bit
1dnorthBoundLatitude0..1Float
32-bit
2Number of groupsnumGRP1Integer
unsigned
8-bit
The number of data values groups contained in this instance group.
Value: 1
3Longitude of grid origingridOriginLongitude1Float
64-bit
Longitude or easting of grid origin.
Unit: (to correspond with previously defined Coordinate Reference System)
4Latitude of grid origingridOriginLatitude1Float
64-bit
Latitude or northing of grid origin.
Unit: (to correspond with previously defined Coordinate Reference System)
5Grid spacing, longitudegridSpacingLongitudinal1Float
64-bit
Cell size in x dimension.
6Grid spacing, latitudegridSpacingLatitudinal1Float
64-bit
Cell size in y dimension.
7Number of points, longitudenumPointsLongitudinal1Integer
unsigned
32-bit
Number of points in x dimension.
8Number of points, latitudenumPointsLatitudinal1Integer
unsigned
32-bit
Number of points in y dimension.
9Start sequencestartSequence1StringGrid coordinates of the grid point to which the first in the sequence of values is to be assigned.
The choice of a valid point for the start sequence is determined by the sequencing rule.
Format: n, n
Example: “0,0” (without quotes)
10Vertical datumverticalDatum0..1Integer
unsigned
16-bit
see remark Table 6-2
row vertical datum
and [mvdvdr]
Mandatory for feature instance groups with a different vertical datum from that specified in the Root Group
(prohibited otherwise)
11Vertical datum referenceverticalDatumReference0..1Integer
unsigned
8-bit
The only allowed value is 1: s100VerticalDatum
(see part=10c,table=23).
see [mvdvdr]
Mandatory if this value were to differ from what is contained in the Root Group

The gridOriginLongitude, gridOriginLatitude, gridSpacingLongitudinal, and gridSpacingLatitudinal attributes should be in the same geographic units as the bounding box. Note that this practice deviates from S-100 where it indicates that this value should be in Arc Degrees.

numPointsLongitude and numPointsLatitude must contain the number of cells in the x and y dimensions of the values table.

The S-102 uses the “Overriding of Attributes” concept of the part=10c,clause=9.7.1. This usage allows the feature instance group to overwrite the attributes of a higher group, in this case the verticalDatum. The default vertical datum is specified in the root group (see Table 6-2). The feature instance group for this default vertical datum must not use the additional attributes verticalDatum and verticalDatumReference (on the feature instance group).

If multiple vertical datums are present in the product, a separate feature instance group must be created for each vertical datum. These feature instance groups must use the additional attribute verticalDatum (on the feature instance group).

Note: At present, this Product Specification does not allow values other than 1: s100VerticalDatum for verticalDatumReference. However, if future changes allow the value of 2: EPSG (and if the value at the feature instance group differs from what is contained in the Root Group), then this value would become mandatory.

According to S-100, either the BoundingBox at the Feature Instance Group or the domainExtent.polygon must be specified. If domainExtent.polygon is specified, the BoundingBox is not specified in this case. The grid cells that do not belong to the area of the respective vertical datum should be assigned the fill value. If more than one domainExtent.polygon is used, those of different feature instance groups should not overlap. At positions where the polygons of different Feature Instance groups touch, the edges should be identical. The domainExtent.polygon does not have to follow grid cell boundaries but is an independent vector geometry based on the SoundingDatum surface from S-101. The domainExtent.polygon only supports a simple polygon geometry in accordance with part=10c,table=11. The mapping of multi-polygons and inner rings is not possible.

6.2.6  The values group — Group_001

This group contains 5 attributes, all of which are mandatory. According to part=10c,table=19, timePoint applies because the dataCodingFormat = 2. The other four attributes for this group are an extension of this Product Specification and, thus, are not defined by part=10c. Table 6-7 lists all 5 attributes.

Table 6-7 — Attributes of values group

NoNameCamel CaseMultData TypeRemarks
1minimum DepthminimumDepth1Float
32-bit
The minimum depth value in the values dataset(s) of this group
2maximum DepthmaximumDepth1Float
32-bit
The maximum depth value in the values dataset(s) of this group
3minimum UncertaintyminimumUncertainty1Float
32-bit
The minimum uncertainty value in the values dataset(s) of this group. If no uncertainty values are in the dataset(s) the value must be the fillValue
4maximum UncertaintymaximumUncertainty1Float
32-bit
The maximum uncertainty value in the values dataset(s) of this group. If no uncertainty values are in the dataset(s) the value must be the fillValue
5Time stamptimePoint1StringBecause S-102 specifies survey dates elsewhere in its structure, this value should always be the fill value:
00010101T000000Z

The group contains an HDF5 dataset named values containing the bathymetric gridded data.

6.2.7  BathymetryCoverage feature instance group — values dataset

This dataset contains the compound data arrays containing bathymetric gridded data. These components are explained below.

For bathymetric gridded data, the dataset includes a two-dimensional array containing always the depth and under certain conditions uncertainty data. These dimensions are defined by numPointsLongitudinal and numPointsLatitudinal. By knowing the grid origin and the grid spacing, the position of every grid point and grid cell can be simply computed.

If the uncertainty for each grid cell is equal, it is not necessary to store it at each cell in the grid. The uniqueness of the uncertainty results from the equality of the attributes minimumUncertainty and maximumUncertainty of Group_001 of the BathymetryCoverage (see Table 6-7 No. 3 & 4). If the uncertainty values at the grid cells are omitted, it must be ensured that the entry of the uncertainty of the BathymetryCoverage in the Group_F is also omitted (see Table 6-3). This type of storage technique can reduce the amount of memory required for the uncertainty without loss of information. The uncertainty of each grid cell can be immediately obtained from the minimumUncertainty or maximumUncertainty attributes of Group_001 of the BathymetryCoverage.

If the uncertainty is not the same for each grid cell, it must be stored at each cell in the grid. For unknown or unused uncertainty data, it must be filled with the fillValue specified in the Group_F feature information dataset.

The grid cell values are stored in two-dimensional arrays with a prescribed number of columns (numCOL) and rows (numROW). This grid is defined as a regular grid (dataCodingFormat = 2); therefore, the depth and uncertainty values will be for each cell in the grid. The data type of the array values is a compound with one or two members.

6.2.8  Root QualityOfBathymetryCoverage

The QualityOfBathymetryCoverage container group has the same metadata attributes as BathymetryCoverage container group (see Table 6-4). The values of the attributes must also be the same as the BathymetryCoverage container group. An exception is the attribute dataCodingFormat, which must be ‘9’. The use of multiple BathymetryCoverage Feature Instance groups (different Vertical Datums) does not affect the multiplicity of the QualityOfBathymetryCoverage, which remains 0 to 1. This means that the different BathymetryCoverage Feature Instance groups share a common QualityOfBathymetryCoverage.

The QualityOfBathymetryCoverage container group contains an additional 1-dimensional array named featureAttributeTable (part=10c,table=9; part=10c,clause=9.6.2). This dataset is mandatory within the QualityOfBathymetryCoverage group. Each element of this array is a metadata record of HDF5 compound type. The fields are described in Table 6-8 below.

Table 6-8 — Elements of featureAttributeTable compound datatype

NoAttributeDescriptionMultData TypeRemarks
1idMetadata record identifier1Integer
unsigned
32-bit
Each record must have a unique identifier.
2dataAssessmentThe categorization of the assessment level of bathymetric data for an area.0..1Integer
unsigned
8-bit
*1: Assessed
*2: Unassessed
*3: Oceanic
3featuresDetected.leastDepthOfDetectedFeaturesMeasuredExpression stating if the least depth of detected features in an area was measured.0..1Integer
unsigned
8-bit
Boolean, Values:
*1 (TRUE)
*0 (FALSE).
See Clause 6.2.8, Note 1.
4featuresDetected.significantFeaturesDetectedA statement expressing if significant features have or have not been detected in the course of a survey.0..1Integer
unsigned
8-bit
Boolean, Values:
*1 (TRUE)
*0 (FALSE).
See Clause 6.2.8, Note 2.
5featuresDetected.sizeOfFeaturesDetectedThe size of detected bathymetric features in an area.0..1Float
32-bit
See Clause 6.2.8, Note 3 and Clause 6.2.8, Note 4.
6featureSizeVarPercentage of depth that a feature of such size could be detected.0..1Float
32-bit
Set to zero if the feature size does not scale with depth.
See Clause 6.2.8, Note 3 and Clause 6.2.8, Note 4.
7fullSeafloorCoverageAchievedExpression stating if full seafloor coverage has been achieved in the area by hydrographic surveys.0..1Integer
unsigned
8-bit
Boolean, Values:
*1 (TRUE)
*0 (FALSE).
See Clause 6.2.8, Note 5.
8bathyCoverageFalse for grid cells populated by interpolation.0..1Integer
unsigned
8-bit
Boolean, Values:
*1 (TRUE)
*0 (FALSE).
See Clause 6.2.8, Note 6.
9zoneOfConfidence.horizontalPositionUncertainty.uncertaintyFixedThe best estimate of the fixed horizontal or vertical accuracy component for positions, depths, heights, vertical distances, and vertical clearances.0..1Float
32-bit
10zoneOfConfidence.horizontalPositionUncertainty.uncertaintyVariableFactorThe factor to be applied to the variable component of an uncertainty equation so as to provide the best estimate of the variable horizontal or vertical accuracy component for positions, depths, heights, vertical distances, and vertical clearances.0..1Float
32-bit
11surveyDateRange.dateStartThe start date of the period of the hydrographic survey.0..1DateISO 8602:2004 date format.
Complete or truncated date,
see part=1,table=2.
12surveyDateRange.dateEndThe end date of the period of the hydrographic survey.0..1DateISO 8602:2004 date format.
Complete or truncated date,
see part=1,table=2.
13sourceSurveyIDThe survey filename or ID.0..1String
14surveyAuthorityThe authority which was responsible for the survey.0..1String
15typeOfBathymetricEstimationUncertaintyThe measure used to estimate the magnitude of the difference between true and estimated bathymetric depth, after all appropriate corrections are made.0..1EnumerationSee Table 6-9.
See Clause 6.2.8, Note 7.

NOTE 1  A feature in this context is any object, whether manmade or not, projecting above the sea floor, which may be a danger for surface navigation [iho-s44]. Least depth of detected features measured does not describe the least depth of features that were actually detected during a hydrographic survey, but the ability of the survey to detect the least depth of features with a maximum uncertainty as defined in [iho-s44].

NOTE 2  A feature in this context is any object, whether manmade or not, projecting above the sea floor, which may be a danger for surface navigation [iho-s44]. Significant features detected does not describe if significant features were actually detected during a hydrographic survey, but whether the survey had the capacity to detect significant features.

NOTE 3  The role of the attribute, featureSizeVar is described in Clause 3.1. The expectation is that featureSizeVar will be set to zero if the feature size does not scale with depth. As with featureSize, featureSizeVar should be ignored if significantFeatures is False.

NOTE 4  When both featureSize and featureSizeVar are present, the greater of the two should be considered valid.

NOTE 5  Full seafloor coverage achieved applies to both the spatial completeness of feature detection and to the spatial completeness of the measurement of the regular seafloor. The former is further specified by the complex attribute features detected; the latter by the attributes depth range maximum value and depth range minimum value.

NOTE 6  The attribute bathyCoverage is especially useful in side-scan surveys which are characterized by gaps in bathymetric observations with full coverage side-scan imagery. In this case, interpolated gaps between bathymetry coverage would show fullSeafloorCoverageAchieved = True and bathyCoverage = False. However, if fullSeafloorCoverageAchieved = False, bathyCoverage must also equal False (e.g., gaps between single beam echosounder data without correlating side-scan sonar coverage).

NOTE 7  Names and listed values which are not currently defined in the IHO GI Registry are subject to change upon acceptance in the Registry.

Table 6-9 — Codes defining how uncertainty of bathymetric depth was determined

Role NameNameDescriptionCodeRemarks
EnumerationS102_BatymetricUncertaintyTypeAn estimate of the magnitude of the difference between true and estimated bathymetric depth, after all appropriate corrections are made.-
ValuerawStandardDeviationRaw standard deviations of soundings that contributed to the grid cell.1-
ValuecUBEStandardDeviationStandard deviation of soundings captured by a CUBE hypothesis (that is, CUBE’s standard output of uncertainty).2-
ValueproductUncertaintyThe greater of (1) standard deviation of the soundings contributing to the depth solution or, (2) the a priori computed uncertainty estimate (that is, modelled Total Vertical Uncertainty).3-
ValuehistoricalStandardDeviationEstimated standard deviation based on historical/archive data.4-
Value(fill value representing “unknown”)(fill value when the uncertainty is an unknown layer type)0This is a “fill value” and will not be in the feature catalogue.

6.2.9  Instance group QualityOfBathymetryCoverage.01

The QualityOfBathymetryCoverage.01 instance group has the same metadata attributes as BathymetryCoverage.01 instance group (see Table 6-6). The values of the attributes must also be the same as the BathymetryCoverage instance group.

6.2.10  Values group for QualityOfBathymetryCoverage

The values group for QualityOfBathymetryCoverage contains no metadata attributes and a single dataset named values, which is described in Clause 6.2.11.

6.2.11  Values dataset for QualityOfBathymetryCoverage

The values dataset for QualityOfBathymetryCoverage is a single two-dimensional array of unsigned integers (the same datatype and size as the “id” field in featureAttributeTable — Table 6-7). The array must have the same dimensions as the values dataset in the BathymetryCoverage feature instance (Clause 6.2.7).

Each cell in this values dataset must be populated with a value that is one of the record identifiers in the featureAttributeTable dataset or with the fill value 0 (zero).

6.2.12  Mandatory Naming Conventions

The following group and attribute names are mandatory in S-100:

  • Group_F

  • featureCode

  • (for S-102)

    • BathymetryCoverage

    • axisNames

    • BathymetryCoverage.01

    • QualityOfBathymetryCoverage.01

    • featureAttributeTable

    • Group_nnn

7  Data Product Delivery

7.1  Introduction

This clause describes how S-102 data will be delivered from the charting authority to the mariner.

Units of Delivery

Exchange Set

Transfer Size

See Clause 7.2.2.

Medium Name

Digital Data Delivery

Other Delivery Information

Each dataset must be contained in a physically separate, uniquely identified file on the transfer medium.

Each exchange set has a single exchange catalogue which contains the discovery metadata for each dataset.

An exchange set is encapsulated into a form suitable for transmission by a mapping called an encoding. An encoding translates each of the elements of the exchange set into a logical form suitable for writing to media and for transmission online. An encoding may also define other elements in addition to the exchange set contents (This is media identification, data extents etc. …​) and may define commercial constructs such as encryption and compression methods.

If the data is transformed in S-102 it must not be changed.

This Product Specification defines the encoding which must be used as a default for transmission of data between parties.

The encoding encapsulates exchange set elements as follows:

Mandatory Elements

  • S-102 datasets — HDF encoding

  • Exchange Catalogue — the XML encoded representation of exchange set catalogue features [discovery metadata].

Optional Elements

  • S-102 Feature Catalogue — If it is necessary to deliver the latest Feature Catalogue to the end user it may be done using the S-102 exchange set mechanism for datasets

  • S-102 Portrayal Catalogue — If it is necessary to deliver the latest Portrayal Catalogue to the end user it may be done using the S-102 exchange set mechanism for datasets.

7.2  Dataset

7.2.1  Dataset management

Three types of dataset files may be produced and contained within an exchange set:

  • New dataset: Initial.

  • New edition of a dataset: Includes new information. New editions must cover at least the same area as its predecessor.

  • Cancellation: The dataset is cancelled and no longer available to be displayed or used.

7.2.1.1  Production of a cancellation

S-102 uses only the fileless cancellation method described in part=17,clause=17-4.4.1. In order to cancel a dataset, the cancelling authority (generally the producer of the original dataset) must:

  1. Prepare an exchange catalogue with an S100_DatasetDiscoveryMetadata block with field values as described in Clause 7.2.1.2.

  2. Complete other parts of the exchange catalogue as required by Clause 8.4 (for example, provide discovery metadata for a replacement dataset if such is included in the same exchange set).

  3. Sign and distribute the exchange catalogue in a normally structured exchange set.

7.2.1.2  Metadata for cancellation

S-102 uses only the fileless cancellation method described in part=17,clause=17-4.4.1. For a cancellation, set:

  • fileName = fileName of the cancelled dataset

  • purpose = cancellation

  • issueDate and issueTime = the issue date and time of the cancellation

  • replacedData = true if and only if the cancelled dataset is replaced by another dataset; otherwise false. This attribute must be populated for a cancellation.

  • dataReplacement = fileName of the replacement dataset (if and only if the cancelled dataset is replaced by another dataset). This attribute must be populated when replacedData=true.

  • all other mandatory attributes to the same values as in the discovery metadata block for the dataset being cancelled.

7.2.2  Dataset size

S-102 delivery will take place in one form: network transfer to platform (that is, internet download). An example scenario has been provided below:

NOTE  The use of 10 MB in this and other sections should be treated as informative information only. Additionally, any computed values associated with either file size limit should be treated as approximate answers. Final selection of an appropriate file size limit or grid resolution is left to the discretion of the data producer.

Network Transfer

To minimize overall file size, the HO produces a 10 MB file for wireless transmission to marine vessels. In uncompressed form, this file would contain roughly 600 by 600 grid cells.

Table 7-1 provides general information to aid in the compilation of S-102 data for specific charting scales.

7.2.2.1  S-102 grid resolution and tiling

Table 7-1 — Informative Grid Resolution and Resulting Tile Size at Chart Scale

ScaleInformative Grid ResolutionResulting Tile Size @ 10 MB

NULL (only allowed on minimum display scale where the maximum display scale = 10,000,000)

Approximate Linear Distance in Nautical Miles (M) for a 600 X 600 cell grid

1:10,000,000

900 metres

291 X 291

1:3,500,000

900 metres

291 X 291

1:1,500,000

450 metres

145 X 145

1:700,000

210 metres

68 X 68

1:350,000

105 metres

34 X 34

1:180,000

54 metres

17.5 X 17.5

1:90,000

27 metres

8.7 X 8.7

1:45,000

13 metres

4.2 X 4.2

1:22,000

6 metres

1.9 X 1.9

1:12,000

3 metres

1.0 X 1.0

1:8,000

2 metres

0.6 X 0.6

1:4,000

1 metres

0.3 X 0.3

1:3,000

1 metres

0.3 X 0.3

1:2,000

1 metres

0.3 X 0.3

1:1,000

1 metres

0.3 X 0.3

7.2.3  Dataset file naming

Dataset naming must follow a standard pattern to give implementers greater predictability of incoming datasets (see part=17,clause=4.3). S-102 dataset naming conventions must follow these rules.

102YYYYØØØØØØØØØØØØ.H5

102

the first 3 characters identify the dataset as an S-102 dataset (mandatory).

YYYY

the fourth to seventh characters identify the producer code according to the Producer Code Register.

ØØØØ

the eighth to the maximum nineteenth characters are optional and may be used in any way by the producer to provide the unique file name. The following characters are allowed in the dataset name: A to Z, 0 to 9 and the special character _ (underscore).

H5

denotes an HDF5 file.

7.3  Exchange Set

The structure of an S-102 Exchange Set must be according to the structure described below, which is based on part=17,clause=4.2.

  1. An S-102 Exchange Set must contain an Exchange Set Catalogue, CATALOG.XML, its digital signature CATALOG.SIGN, and may contain any number of S-102 conformant dataset files, support files, and Catalogue files.

  2. All content must be placed inside a top root folder named S100_ROOT. This is the only top level root folder in an Exchange Set containing only S-100 products.

  3. The S100_ROOT folder must contain a subfolder named S-102. This subfolder holds content specific to the S-102 Product Specification.

  4. The S-102 subfolder must contain subfolders for the component dataset files (DATASET_FILES) and Catalogues (CATALOGUES) as required.

  5. The required Exchange Set Catalogue XML document instance must be named CATALOG.XML and placed in the S100_ROOT folder, together with its digital signature (CATALOG.SIGN) file. All other digital signatures are included within their corresponding resource metadata records in the CATALOG.XML.

  6. Support files are not allowed in S-102 exchange sets for this edition of S-102.

7.4  Exchange Catalogue

The Exchange Catalogue acts as the table of contents for the Exchange Set. The Catalogue file of the Exchange Set must be named CATALOG.XML. No other file in the Exchange Set may be named CATALOG.XML. The contents of the Exchange Catalogue are described in Section 8.

7.5  Data integrity and encryption

part=15 defines the algorithms for compressing, encrypting and digitally signing datasets based on the S-100 Data Model. The individual Product Specifications provide details about which of the elements are being used and on which files in the dataset.

7.5.1  Use of compression

The data producer decides if compression will be used on the S-102 product files (HDF5). It is expected that a hydrographic office will make a policy decision and that all the S-102 datasets from the producer will be either compressed or uncompressed.

It is recommended to compress all the dataset files, for example HDF5 files. The ZIP compression method defined in part=15,clause=5.2 must be applied to the product files.

7.5.2  Use of data protection

It is recommended to encrypt all the dataset files, for example HDF5. The encryption method defined in part=15 must be applied.

7.5.3  Use of digital signatures

Digital signatures shall be used on all files included in a S-102 compliant Exchange Set to meet the requirements of IMO resolution MSC.428(98) to reduce cyber security risks among users, especially when used in navigations systems at sea. The recommended signature method is defined in part=15.

The digital signature information is encoded in the corresponding discovery block in the exchange catalogue for each file included in the Exchange Set.

8  Metadata

8.1  Introduction

The Metadata elements used in the Bathymetric Surface product are derived from S-100 and from [iso-19115-1] and [iso-19115-2]. Optionally additional metadata may be derived from [iso-ts-19130] and [iso-ts-19130-2] especially metadata relating to the sonar equipment which may have been used to acquire the bathymetric data.

S-102 metadata is encoded in two places:

  • Metadata used for the discovery, identification, and use of S-102 datasets in S-100-based navigations systems (specifically, an S-100-capable ECDIS) is encoded in the exchange catalogue. This metadata conforms to S-100 Part 17, with product-specific restrictions added.

  • Metadata required by the S-100 HDF5 encoding (part=10c) and product-specific metadata defined by this product specification are encoded at various levels in the HDF5 group hierarchy, as specified by part=10c or Clause 6.2.

8.2  Exchange Set metadata

For information exchange, there are several categories of metadata required: metadata about the overall Exchange Catalogue, metadata about each of the datasets contained in the Catalogue.

Figure 8-1 depicts the relationships of exchange set elements (datasets and feature/portrayal catalogues) and exchange set metadata. This figure is derived from part=17,figure=2 with relationships not applicable to S-102 omitted.

Figure 8-2 depicts the structure of the exchange catalogue and its component discovery metadata blocks. The structure is the same as in part=17.

More detailed information about the various classes is shown in Figure 8-3 with further description in Table 8-1 to Clause 8.8.2. In the cases in which classes are used without modification, refer to part=17 for their descriptions.

The discovery metadata classes have numerous attributes which enable important information about the datasets to be examined without the need to process the data (e.g., decryption, decompression, loading). Other Catalogues can be included in the Exchange Set in support of the datasets such as Feature and Portrayal.

Figure 8-1 — Components and associated metadata for the S-102 exchange set (part=17,figure=2 with items not used by S-102 omitted)

Figure 8-2 — Relationship between exchange catalogue, discovery metadata, and dataset (part=17,figure=6 with items not used by S-102 omitted)


Figure 8-3 — S-102 Exchange Set Class Details (part=17,figure=7 with items not used by S-102 omitted)


The following clauses define the mandatory and optional metadata needed for S-102. In some cases, the metadata may be repeated in a national language. If this is the case it is noted in the Remarks column.

The XML schemas for S-102 exchange catalogues will be available from the IHO Geospatial Information (GI) Registry and/or the S-100 GitHub site (https://github.com/IHO-S100WG).

The S-102 exchange catalogue uses the S-100 exchange catalogue schemas which are available from the S-100 schema server at https://schemas.s100dev.net (downloadable archives are also available on the site for offline use). Implementation of the S-102-specific constraints described in following clauses below is left to developer decision as it can be done in various ways depending on implementation frameworks and the requirements of production or application software.

8.3  Language

The exchange language must be English.

Character strings must be encoded using the character set defined in [iso-10646-1], in Unicode Transformation Format-8 (UTF-8). A BOM (byte order mark) must not be used.


8.4  S100_ExchangeCatalogue

Each Exchange Set has a single S100_ExchangeCatalogue which contains meta information for the data in the Exchange Set.

S-102 uses S100_ExchangeCatalogue without modification.

8.4.1  S100_ExchangeCatalogueIdentifier

S-102 uses S100_ExchangeCatalogueIdentifier without modification.

8.4.2  S100_CataloguePointOfContact

S-102 uses S100_CataloguePointOfContact without modification.

8.5  S100_DatasetDiscoveryMetadata

Dataset discovery metadata in S-102 restricts certain attributes and roles as described in Table 8-1. Optional S-100 attributes which are mandatory in S-102 are indicated in the Remarks column.

Table 8-1 — S100_DatasetDiscoveryMetadata parameters

Role nameNameDescriptionMultTypeRemarks

Class

S100_DatasetDiscoveryMetadata

Metadata about the individual datasets in the Exchange Catalogue

-

-

The optional S-100 attributes updateNumber, updateApplicationDate, referenceID, and temporalExtent are not used in S-102.
References to support file discovery metadata are not permitted because S-102 does not use support files.

Attribute

fileName

Dataset file name

1

URI

See part=1,clause=4.6
Format: file:/S-102/DATASET_FILES/<dsname>
Dataset file name <dsname> must be according to format defined in Clause 7.2.3.

Attribute

description

Short description giving the area or location covered by the dataset

0..1

CharacterString

For example a harbour or port name, between two named locations, etc.

Attribute

datasetID

Dataset ID expressed as a Maritime Resource Name

0..1

URN

The URN must be an MRN.
See part=3,clause=10

Attribute

compressionFlag

Indicates if the resource is compressed

1

Boolean

True indicates a compressed dataset resource.
False indicates an uncompressed dataset resource.

Attribute

dataProtection

Indicates if the data is encrypted

1

Boolean

True indicates an encrypted dataset resource.
False indicates an unencrypted dataset resource.

Attribute

protectionScheme

Specification of method used for data protection

0..1

S100_ProtectionScheme

Populate if and only if dataProtection = True.

Attribute

digitalSignatureReference

Specifies the algorithm used to compute digitalSignatureValue

1

S100_SE_DigitalSignatureReference

See part=15,clause8.11.7 & Clause 8.9

Attribute

digitalSignatureValue

Value derived from the digital signature

1..*

S100_SE_DigitalSignature

see part=15,clause=15-8.11.3
The value resulting from application of digitalSignatureReference
Implemented as the digital signature format specified in part=15

Attribute

copyright

Indicates if the dataset is copyrighted

1

Boolean

True indicates the resource is copyrighted.
False indicates the resource is not copyrighted.

Attribute

classification

Indicates the security classification of the dataset

1

Class
MD_SecurityConstraints>MD_ClassificationCode (codelist)

Mandatory in S-102

  1. unclassified

  2. restricted

  3. confidential

  4. secret

  5. top secret

  6. sensitive but unclassified

  7. for official use only

  8. protected

  9. limited distribution

Attribute

purpose

The purpose for which the dataset has been issued

1

S100_Purpose

Mandatory in S-102

Attribute

notForNavigation

Indicates the dataset is not intended to be used for navigation

1

Boolean

True indicates the dataset is not intended to be used for navigation.
False indicates the dataset is intended to be used for navigation.

Attribute

specificUsage

The use for which the dataset is intended

0..1

MD_USAGE>specificUsage (character string)

-

Attribute

editionNumber

The edition number of the dataset

1

Integer

When a data set is initially created, the Edition number 1 is assigned to it. The Edition number is increased by 1 at each new Edition. Edition number remains the same for a re-issue.
Mandatory in S-102

Attribute

issueDate

Date on which the data was made available by the Data Producer

1

Date

-

Attribute

issueTime

Time of day at which the data was made available by the Data Producer

0..1

Time

The S-100 datatype Time
May be required if multiple instances of a product are issued on the same day.

Attribute

boundingBox

The extent of the dataset limits

1

EX_GeographicBoundingBox

Mandatory in S-102
Defined as a rectangle coincident with the outermost cell boundaries of the dataset.

Attribute

productSpecification

The Product Specification used to create this dataset

1

S100_ProductSpecification

Table 8-5

Attribute

producingAgency

Agency responsible for producing the data

1

CI_Responsibility>CI_Organisation

See part=17,table=17-3

Attribute

producerCode

The official IHO Producer Code from S-62

1

CharacterString

Mandatory in S-102

Attribute

encodingFormat

The encoding format of the dataset

1

S100_EncodingFormat

The only allowed value is HDF5
Table 8-4

Attribute

dataCoverage

Provides information about data coverages within the dataset

1..*

S100_DataCoverage

Mandatory in S-102
Table 8-2

Attribute

comment

Any additional information

0..1

CharacterString

-

Attribute

defaultLocale

Default language and character set used in the dataset

0..1

PT_Locale

In absence of defaultLocale, the language is English, and the character set is UTF-8.

Attribute

otherLocale

Other languages and character sets used in the dataset

0..*

PT_Locale

Attribute

metadataPointOfContact

Point of contact for metadata

0..1

CI_Responsibility>CI_Individual
or
CI_Responsibility>CI_Organisation

Only if metadataPointOfContact differs from producingAgency

Attribute

metadataDateStamp

Date stamp for metadata

0..1

Date

May or may not be the issue date

Attribute

replacedData

Indicates if a cancelled dataset is replaced by another data file(s)

0..1

Boolean

See note following part=17,table=S100_DatasetDiscoveryMetadata
Mandatory when purpose = cancellation

Attribute

dataReplacement

Dataset name

0..*

CharacterString

A dataset may be replaced by 1 or more datasets.
Dataset name must be according to format defined in Clause 7.2.3.
For example, 102DE00KD54.H5
See note following part=17,table=S100_DatasetDiscoveryMetadata
Mandatory when replacedData = true

Attribute

navigationPurpose

Classification of intended navigation purpose (for Catalogue indexing purposes)

1..3

S100_NavigationPurpose

If Product Specification is intended for creation of navigational products, this attribute should be mandatory.
Mandatory in S-102

Role

resourceMaintenance

Information about the frequency of resource updates, and the scope of those updates

0..1

MD_MaintenanceInformation

S-100 restricts the multiplicity to 0..1 and adds specific restrictions on the ISO 19115 structure and content. See part=17.
Format: PnYnMnDTnHnMnS (XML built-in type for ISO 8601 duration). See part=17,clause=4.9.
S-102 discovery metadata blocks should populate maintenance information if and only if the date of the next edition is definite, whether it is due on a regular or irregular schedule.

8.5.1  S100_NavigationPurpose

S-102 uses S100_NavigationPurpose without modification.

8.5.2  S100_DataCoverage

S-102 uses S100_DataCoverage without modification, but with additional remarks and changes to the multiplicity.

Table 8-2 — S100_DataCoverage parameters

Role nameNameDescriptionMultTypeRemarks

Class

S100_DataCoverage

A spatial extent where data is provided along with the display scale information for the provided data

-

-

This field is used by user systems as part of the data loading and unloading algorithms, and it is strongly encouraged that Product Specifications mandate the use of one or more of the displayScale provided as part of S100_DataCoverage.

Attribute

boundingPolygon

A polygon which defines the actual data limit

1

EX_BoundingPolygon

Clause 8.5.2, Note

Attribute

temporalExtent

Specification of the temporal extent of the coverage

0

S100_TemporalExtent

The temporalExtent is not used in S-102.

Attribute

optimumDisplayScale

The scale at which the data is optimally displayed

0..1

Integer

Example: A scale of 1:25000 is encoded as 25000

Attribute

maximumDisplayScale

The maximum scale at which the data is displayed

0..1

Integer

Attribute

minimumDisplayScale

The minimum scale at which the data is displayed

0..1

Integer

Attribute

approximateGridResolution

The resolution of gridded or georeferenced data (in metres)

1..2

Real

Mandatory in S-102
A single value may be provided when all axes have a common resolution.
For multiple value provision, use axis order as specified in dataset.
For example, for 5 metre resolution, the value 5 must be encoded.
If the grid cell size varies over the extent of the grid
(i.e., when using a geographic grid), an approximated value should be used.

NOTE  boundingPolygon is restricted to a single GML Polygon with one exterior and 0 or more interiors expressed as Linear Rings using SRS EPSG:4326. The exterior and optional interiors shall be composed of a closed sequence of >=4 coordinate positions expressed individually or as a list (posList). The GML polygon shall have a valid GML identifier.

8.5.3  S100_Purpose

S-102 uses S100_Purpose without modification, but with a restriction on the allowed values.

Table 8-3 — S100_Purpose

Role nameNameDescriptionCodeRemarks

Enumeration

S100_Purpose

The purpose of the dataset

-

The S-100 values update, reissue, and delta are not used in S-102.

Value

newDataset

Brand new dataset

1

No data has previously been produced for this area.

Value

newEdition

New edition of the dataset or Catalogue

2

Includes new information which has not been previously distributed by updates.

Value

cancellation

Dataset or Catalogue that has been cancelled

5

Indicates the dataset or Catalogue should no longer be used and can be deleted.

8.5.4  S100_EncodingFormat

S-102 uses S100_EncodingFormat with a restriction on the allowed values to permit only the S-100 HDF5 format for S-102 datasets.

Table 8-4 — S100_EncodingFormat parameters

Role nameNameDescriptionCodeRemarks

Enumeration

S100_EncodingFormat

The encoding format

-

The only value allowed in S-102 is “HDF5”.

Value

HDF5

The HDF5 data format as defined in part=10c

3

-

8.5.5  S100_ProductSpecification

S-102 uses S100_ProductSpecification without modification, but with additional remarks and changes to the multiplicity.

Table 8-5 — S100_ProductSpecification parameters

Role nameNameDescriptionMultTypeRemarks

Class

S100_ProductSpecification

The Product Specification contains the information needed to build the specified product.

-

-

-

Attribute

name

The name of the Product Specification used to create the datasets

1

CharacterString

The name in the GI Registry should be used for this field.
For S-102, this name is “Bathymetric Surface” (as of 25 June 2024).

Attribute

version

The version number of the Product Specification

1

CharacterString

TR 2/2007 specifies versioning of Product Specifications
Example: 3.0.0 for S-102 Edition 3.0.0

Attribute

date

The version date of the Product Specification

1

Date

-

Attribute

productIdentifier

Machine readable unique identifier of a product type

1

CharacterString
(Restricted to Product ID values from the IHO Product Specification Register in the IHO Geospatial Information (GI) Registry)

For S-102, this identifier is “S-102” (without quotes).

Attribute

number

The number used to lookup the product in the Product Specification Register of the IHO GI registry

1

Integer

For IHO Product Specifications, these numbers should be taken from the IHO Product Specification Register in the IHO GI Registry.
The corresponding Idx-number of the IHO Registry for S-102 is numbered 199.

Attribute

compliancyCategory

The level of compliance of the Product Specification to S-100

0..1

S100_CompliancyCategory

See part=4a,clause=4a-5.5 and Clause 8.5.6 below.

8.5.6  S100_CompliancyCategory

S-102 exchange sets conforming to this edition of S-102 and using a CRS from the EPSG registry may be encoded as category 3 or 4 when the compliancyCategory metadata attribute is populated. Because S-98 interoperability assumes category4 datasets, category4 may be used for test purposes, though the absence of test datasets and of a published IHO interoperability catalogue mean this edition of S-102 does not yet qualify for category4. Given the uncertainty about interoperability testing requirements and availability of test datasets, the S-100 WG chair and S-102 PT chair should be consulted for up-to-date guidance.

Table 8-6 — S100_CompliancyCategory

Role NameNameDescriptionCodeRemarks

Enumeration

S100_CompliancyCategory

-

-

S-102 should use category3 or category4, subject to the guidance provided in Clause 8.5.6.

Value

category3

IHO S-100 compliant with standard encoding

3

Qualifies as category2; plus “The Product Specification uses only an encoding method defined in part=10;and!part=4a,clause=5.5.3

Value

category4

IHO S-100 and IMO harmonized display compliant

4

Qualifies as category3; plus additional requirements, including a portrayal catalogue, cybersecurity (digital signatures and encryption), test material, use of a CRS from the EPSG Registry, and compliance with the IHO S-98 interoperability catalogue. part=4a,clause=5.5.4

8.5.7  S100_ProtectionScheme

S-102 uses S100_ProtectionScheme without modification.

8.6  MD_MaintenanceInformation

S-102 uses MD_MaintenanceInformation without modification.

8.7  MD_MaintenanceFrequencyCode

S-102 uses MD_MaintenanceFrequencyCode without modification.

8.8  S100_CatalogueDiscoveryMetadata

S-102 uses S100_CatalogueDiscoveryMetadata without modification.

8.8.1  S100_CatalogueScope

S-102 uses S100_CatalogueScope without modification.

8.8.2  PT_Locale

S-102 uses PT_Locale without modification. The class PT_Locale is defined in [iso-19115-1]. LanguageCode, CountryCode, and MD_CharacterSetCode are ISO codelists which are defined in a codelists file which is part of the S-100 Edition 5.2.0 schema distribution.

8.9  Certificates and Digital Signatures

The classes S100_SE_CertificateContainerType (part=15,clause=8.11.1), S100_SE_DigitalSignatureReference (part=15,clause=8.11.7), and S100_SE_DigitalSignature are defined in part=15 and implemented in the S-100 generic schemas.

In accordance with part=15, only the ECDSA algorithm is allowed from the S100_SE_DigitalSignatureReference enumeration.

S-102 uses S100_SE_DigitalSignature without modification. As stated in part=15,clause=15-8.11.3:

“The class S100_SE_DigitalSignature is realized as one of either S100_SE_SignatureOnData (a digital signature of a particular identified resource) or an additional digital signature defined using the class S100_SE_AdditionalSignature, each of which is either a S100_SE_SignatureOnData or S100_SE_SignatureOnSignature element as described in part=15,clause=8.8. part=17 metadata thus allows for multiple digital signatures, a single mandatory S100_SE_SignatureOnData and any number of additional signatures, either of the data or other signatures.”



Annex A
Data Classification and Encoding Guide

A.1  Features

A.1.1  BathymetryCoverage

Table A-1 — BathymetryCoverage feature parameters

Term: Bathymetry Coverage

IHO Definition: A set of value items required to define a dataset representing a depth calculation and its associated uncertainty.

Primitive: S100_IF_GridCoverage

AttributeAllowable Encoding ValueTypeMultiplicity

depth

Must be in decimal metres with resolution not to exceed 0.01 metres

real (32-bit Float)

1

uncertainty

Must be in decimal metres with resolution not to exceed 0.01 metres

real (32-bit Float)

0..1

A.1.2  QualityOfBathymetryCoverage

Table A-2 — QualityOfBathymetryCoverage feature parameters

Term: Quality Of Bathymetry Coverage.

IHO Definition: A set of references to value records that provide localised information about depth, uncertainties, and bathymetry coverage metadata.

Primitive: S100_IF_GridCoverage

AttributeConstraintTypeMultiplicity

iD

Each record must have a unique identifier.

unsigned 32-bit Integer

1

A.2  Feature Attributes

A.2.1  BathymetryCoverage

Table A-3 — BathymetryCoverage feature attribute parameters

IHO Definition: depth. The vertical distance from a given water level to the bottom [[iho-s32]].

Unit: metres

Resolution: 0.01

Remarks:

  • Drying heights (drying depths) are indicated by a negative value.

IHO Definition: uncertainty. Estimate characterising the range of values within which the true value of a measurement is expected to lie as defined within a particular confidence level. It is expressed as a positive value.

Unit: metres

Resolution: 0.01

Remarks:

  • Represents a +/- value defining the possible range of associated depth.

  • Expressed as a positive number.

A.2.2  QualityOfBathymetryCoverage

Table A-4 — QualityOfBathymetryCoverage feature attribute parameters

IHO Definition: iD. Meta data record identifier for QualityOfBathymetryCoverage

Unit:

Resolution:

Remarks: